With the growing number of wireless communication devices, there is a need to strengthen and simplify a user's authentication process for logging into independent secure websites provided by third-party internet content providers. To gain access into these websites, users are required to set up unique user IDs and passwords for each service. However, using multiple user IDs and passwords that are subject to different password policies is cumbersome and prone to security breaches. Therefore, a method for strengthening the security level of password management while simplifying the user authentication process for wireless communication device user is greatly needed.
Because third-party web service providers maintain separate agreements with wireless network operators, it is impractical to base user authentication process on third-party services on the access network, be they a wireless network such as the radio access network (RAN), a fixed or low-mobility wireless network, (e.g., IEEE 802.16-type networks), or a fixed wireline network. Because service providers and users often access services through multiple RANs, wireless networks, or fixed networks using single identities, users and third-party service providers will likely implement SSO operations across different networks, where the network operators can maintain control over granting user permission
In one scenario, wireless network operators and third-party ID service providers could supply uniform user IDs to users to facilitate seamless service continuity across different types of networks, operators, and service providers. Uniform user IDs could resolve transitional problems that result from frequent and high-volume changes across services of different network types and entities, and service provider boundaries.
Poor management of passwords or authentication credentials can have devastating effects on security. Attackers can gain access to sensitive data through weak or stolen passwords. Poor password management may also lead to increases in operational costs. For example, Help Desk call volumes may dramatically increase with an increase in the number of users who call to retrieve or reset their lost or forgotten passwords.
The following are prior art solutions for improving password management as will be described in more detail hereinafter: specific password policies, password-less authentication, biometric factors, password synchronization, credential mapping, enterprise single sign-on (E-SSO), combining E-SSO with password synchronization, web single sign-on (web-SSO), and security assertion mark-up language (SAML).
In order to strengthen user password security levels, an organization may implement specific passwords policies. Common password policies may require users to set up hard-to-guess passwords or to change passwords frequently. Password policies may also log user password history to prevent immediate password reuse or implement lock-out policies to lock out anyone who fails to log-in after a certain number of attempts. While implementing good password policies may strengthen password security, it may also encourage users to set up patterned passwords that are easy to remember and manage. For example, a user might create a password using a combination of characters and numbers, such as @#$%9876, to meet complexity requirements of password policies. The user, however, when prompted by the system to change the password, may create a new password using a variation of the old password, such as @#$%8765 or @#$%7654. Use of patterned passwords weakens password security level because knowledge of a user's password history greatly narrows the number of break-in attempts to variations of the old password. Because complex passwords are hard to remember, strict password policies may cause users to use the same passwords for different services. When passwords are shared across different services, a single password compromised in any of the services will lead to compromising of the password in all of the other services.
Password-less authentication is another technique used to improve the security of authentication processes. Individuals and organizations have adopted authentication methods that do not rely on user IDs and passwords, such as smart cards and authentication tokens. A smart card uses a built-in password—a personal identification number (PIN)—to unlock a complex password stored on the card for user authentication purposes. The set-up eliminates the need for a user to enter a password and uses multifactor authentication, the physical smart card and the PIN stored therein, to authenticate a user. However, smart cards have drawbacks such as high up-front costs for setting up the system and high on-going costs for maintaining Help Desk support for lost, stolen, or otherwise compromised cards.
Using biometric factors to authenticate a user has also become popular. Common biometric authentication devices involve retina scanners, fingerprint scanners, and hand scanners. These devices authenticate a user with data derived from the user's physical attributes. A drawback of these devices is that they are expensive to implement and maintain.
Password synchronization is a technology that allows a user to use a single password across multiple systems. In password synchronization, a password is subject to a single security policy for both password reset and password changes. In this technology, a plaintext copy of a password is extracted from one location and placed in one or more external service locations. To achieve this, a copy of user profile for every user must exist on every system at the outset of the deployment project, and maintained throughout the life of the system. Password change in password synchronization can happen with either a one-way push or a bi-directional push. In one-way password push, a password change in a central system is intercepted and pushed to other locations within the network. In bi-directional password push, a password change can be made in any system and is propagated throughout the entire password architecture.
The main problem with one-way password push lies within the security measurement of the systems that store passwords. Because a synchronized password is used across systems, a security breach in any system will result in a disastrous security breach in all systems. Although bidirectional password synchronization provides more user flexibility, it can cause additional problems, such as creating an infinite loop of password changes. Because the system is programmed to propagate new data to the rest of the system, the system may be caught in an endless password update process propagating multiple password changes on a single password.
Accordingly, although password synchronization relieves users from having to remember and manage multiple passwords within a network, password synchronization also weakens password security by allowing a user to use one password to access multiple services.
Credential mapping, commonly referred to as E-SSO, is a technology that stores, retrieves, and “types-in” user IDs and passwords on behalf of a user. To implement E-SSO, a copy of the E-SSO software must be installed on each WTRU. User ID and password for every system and application are stored in a local file, a network-attached database, or a user directory. After the initial setup, users can sign into their workstation, either as they did before, or through a new E-SSO software interface. When users request to connect to applications using their workstation, the E-SSO software automatically populates the user ID and password fields of the applications' login pages.
In an E-SSO system, users sign into their workstation with either one or two sets of user credentials (e.g., user IDs and passwords): 1) when users only need to log into the E-SSO software and not to their workstations; and 2) when users must log into both.
Some E-SSO systems support the use of authentication technologies other than passwords to sign into the workstation and to access a user's credential profile, including smart cards, authentication tokens or biometric samples. In addition, some E-SSO technologies are configured to completely control password management for each target destination. The approach eliminates the need for users to remember their passwords for any target systems. The E-SSO software automatically signs in for the user on behalf of the user.
Under E-SSO, users also do not have to change passwords on target systems. The software recognizes or anticipates password change requests and changes the password accordingly on behalf of the user. The credential mapping password management features work best if the target systems are accessed only through the credential management software.
Although an E-SSO system provides functionalities to safeguard user passwords, the system has the drawback of being costly and cumbersome to set up. Implementing an E-SSO system requires not only creating a login ID profile for each user, but also storing current passwords for each user and for each target application. Setting up an E-SSO system further requires installing client software and deploying credential database for storing user IDs and passwords. The database may be obtained through a dedicated network service, or by extending the scheme of an existing directory (e.g., active directory, LDAP, NDS). A credential database has several requirements of its own. To carry out its purpose, the database must be fast and available, as a failure in this database will prevent large numbers of users from signing into any system. Additionally, the database must also be secure, as a compromise in the database may lead to a compromise of every user credential in all systems.
As a central password control system, E-SSO introduces a single point-of-failure. A user cannot log into any system if the E-SSO system or the credential database is down. In addition, E-SSO technology does not support an authentication process with applications that support multiple user interfaces (e.g., client, web, phone, etc.) Further, because E-SSO relies on Windows “screen scraping” technology, deployment and management of an E-SSO system can be costly, especially across multiple types of workstations. Accordingly, an E-SSO system not only is tedious, time consuming, and costly to set up and enroll, but is also susceptible to a single point-of-failure.
Combining E-SSO with password synchronization can address some of the shortcomings of implementing an E-SSO system alone. For example, without password synchronization technology, users will not be able to use their E-SSO passwords to log into applications using alternative user interfaces. Because users do not necessarily know their own passwords, user who normally uses proprietary clients such as Microsoft Outlook might not be able to access e-mail accounts through web portals. By combining password synchronization with E-SSO, users can use their primary E-SSO passwords to log-in to other applications through alternative interfaces, such as web portals. Further, deploying password synchronization system before deploying E-SSO system reduces time and effort in obtaining a user ID profile for each user.
In E-SSO systems, user credentials are typically encrypted with a key derived from the primary E-SSO password. Loss of a primary E-SSO password, under this configuration, results in a loss of user credentials to every system. Even after the loss E-SSO password is reset, the encrypted credentials will not be accessible, because the credentials are encrypted with a key derived from the lost password. In other words, resetting a user's E-SSO primary password will not retrieve the user's credentials, and the user must re-enroll with the E-SSO system.
To address this problem, an E-SSO system must provide a “back door,” to recover user credentials after an E-SSO password reset. A password reset system must integrate with this back door system or provide its own back door. After resetting a user's primary E-SSO password, a password reset system must recover the user's previous password from the safe storage, decrypt the user's old credentials, and re-encrypt them with the new password and key, so that the E-SSO client software is accessible again.
Integrating password reset, password synchronization, and E-SSO system resolves this problem and allows organizations to enjoy the benefits of rapid deployment, automated sign-on, and self-service problem resolution. However, the combination of technologies does not address the issue of securing passwords and log-in credentials. Further, a compromise in either the client or server software, or the database compromises the user profiles. Lastly, the combination still fails to provide ways to verify the “health” state of the systems engaging in password synchronization and E-SSO. Without this verification, once a user is authorized by the system, the user can access the system even when the system is compromised.
Web-SSO works with applications and resources accessed through a web browser. In web-SSO, access to web resources is intercepted either by a web proxy server or a component on a targeted web server, and unauthenticated users who attempt to access a web resource are diverted to an authentication prompt, and redirected to the original site only after a successful sign-on. Cookies are most often used to track a user's authentication state, and the web-SSO infrastructure extracts user identification information from cookies and passes it onto web resources.
Screen scraping and federation are two most important prior art technologies that are used in web-SSO. A common type of screen scraping is web scraping. Web scraping, also referred to as HTML scraping or page scraping, is a technique wherein a computer program, web scraper, extracts data from a web page. Web scraping can be used in E-SSO or web-SSO.
Screen scraping technologies are useful because web pages are built using text-based mark-up languages (e.g. HTML) which often includes information in a text form. In contrast, data exchange between programs is usually accomplished using data structures designed for machines that are not readily understandable by humans. Similarly, data output intended for users is often not suitable for machine interpretation. Therefore, screen scraping is needed to accomplishing the transfer of data between programs, by first extracting machine-friendly data from HTML and other markup machine languages and then exchanging the extracted machine-friendly data between programs.
When performing screen scraping, reading data from a computer text display is generally done by reading the terminal's memory through its auxiliary port, or by connecting the terminal's output port to another system's input port. In these cases, screen scraping can also refer to computerized parsing of web pages.
Screen scraping is most often done to: (1) interface a legacy system that is incapable of providing an alternative mechanism that is compatible with current hardware; or 2) interface a third-party system that provides a less sophisticated application program interfaces (API). In the latter case, a third-party system may consider screen scraping as unwanted, for reasons such as increased system load, loss of advertisement revenue, or loss of control of information content.
FIG. 1 illustrates exemplary procedures in a prior art WTRU that uses web-SSO with web scraping. In this diagram, it is assumed that the WTRU is equipped with proxy software and that the web-accessing application on the WTRU interacts cooperatively with the SSO proxy software to allow the proxy to establish and control procedures for SSOs into web services. For example, when a browser receives a request to access an URL, it transmits the URL to the SSO proxy software to verify whether web-SSO can be used to access the particular website.
Federation is the second import technology used for web-SSO that uses standard-based protocols to enable one application to assert the identity of a user to a second entity, thereby eliminating the need for redundant authentication. Specification standards that support federation include Liberty Alliance ID-FF, OASIS, SAML, and Shibboleth, which is being developed for Internet2. Liberty Alliance is a central organization that has developed specifications for identity federation framework (ID-FF) and identity web service framework (ID-WSF). The Liberty Alliance provides a set of broad-based industry consortium developing suites that contain specifications defining federated identity management and web services communication protocols. The protocols are designed for both intra-enterprise and inter-enterprise deployments. OASIS is a non-profit organization developing solutions for e-business. SAML, which is currently in version 2.0, is a mark-up language for security assertions, which includes user identification information that enables SSO authentication. Shibboleth is an Internet2 middleware initiative (NMI) project that has created an architecture and open-source implementation for authentication and authorization infrastructure based on federated identity and SAML.
FIG. 2 illustrates procedures for web-SSO by a WTRU user that uses Liberty Alliance ID-FF. In the context of web-SSO, Liberty Alliance enables a user to log into a single account and request services from several services providers within a “circle of trust,” managed by an ID management entity in the network. A distinctive feature of Liberty Alliance is the “federation” process. Instead of deciding what kind of right each user has to access a service provider (SP) without undergoing re-authentication, Liberty Alliance allows users to decide if they want to access an SP without re-authentication. To obtain this right, a user must first be authenticated by an identity provider (IDP) that is recognized by the SP. This makes Liberty Alliance a practical framework for identity management in the context of extended-enterprise applications, wherein users typically entrust the management of personal data to the enterprise.
SAML is an XML standard created by the OASIS organization for exchanging authentication and authorization data between security domains; that is, between an IDP and a SP. FIG. 3 depicts the relationships among the SAML components. SAML tries to solve the web-SSO problem by facilitating seamless and reliable exchanges of authentication procedures and security assertion information between the network entities. The SAML standard utilizes the following components: 1) assertions component; 2) protocols component; 3) bindings component; 4) and profiles component. The assertions component allows one entity to assert the characteristics and attributes of another entity, such as user name, status, email address, membership in groups, etc. Protocol components are encoded in an XML schema and defines a lists of request-response related protocols.
The binding component defines how SAML protocol messages are transported within SOAP messages and how SOAP messages are transported over HTTP. SOAP messages are well-formed XML messages that are constructed according to the W3C organization SOAP version 1.2 envelope and encoding rules. FIG. 4 shows an example of an exchange between SAML components in a typical binding case. The profiles component is the core of the SAML specification; it defines how SAML requests and responses are transported.
Although both Liberty ID-FF and SAML play important roles in strengthening password security levels, neither addresses how to secure sensitive information necessary for the web-SSO within the user's devices or on IDP and SP. Further, because both Liberty ID-FF and SAML ultimately relinquish control of a user authentication process to IDPs and SPs, thereby requiring the disclosure of user personal information, user profiles may be compromised in the process.
Trusted computing techniques have appeared in the literature and in products, mostly under the technical umbrella of the Trusted Computing Group (TCG). Trusted computing is based on physical security of a dedicated, physically isolated hardware module that provides cryptographic functions and protected storage.
The TCG has developed various technologies that provide methods for computing entities to assert the integrity of systems, to validate an authentication process when an appropriate trust level is established, and to perform assessment of and decisions on exchange of information and processing with other devices based on the manifested trust levels of such target devices.
TCG defines a core platform module called the trusted platform module (TPM). FIG. 5 depicts the composition of a TPM, which provides physical protection of the TPM module and its interfaces. The module also provides protection for volatile and non-volatile memory spaces and cryptographic functions for performing encryption and digital signing. TPM uses platform configuration registers (PCR) to capture the “state” of the platform and its software components by HASH extending and user device specific and secure endorsement keys (EK), based on a public key infrastructure (PKI). The EK is never exposed outside, but its aliases, the attestation identity key (AIK), is used to validate the platform's integrity values. Furthermore, TPM uses a process that “seals” data in conjunction with PCR values signed by AIKs in memory, so that data can be accessed or extracted only when platform or software integrity, as measured and verified by the matching PCR values from the TPM and from the sealed memory, is verified.
FIG. 6 illustrates how an external entity (a challenger, or a verifier) can make requests for platform attestation using the TPM, AIKs and the private certification authority (PCA). Such an attestation mechanism, can be useful for improving the trust and security aspects of SSO techniques.
TCG has also specified a detailed TPM software stack (TSS) for use by a computing platform that includes a TPM. Each TSS module comprises components that provide specialized functions. The primary design goals of these components are to supply a single, synchronized entry point into to the TPM, to conceal building command streams with appropriate byte ordering and alignment from the applications, and to manage TPM resources.
FIG. 7 shows the architecture of TPM and TSS layers. TSS modules include the following components: 1) TSS device driver library interface (TDDLI) that interfaces to the standardized TPM device driver library (TDDL); 2) TSS core service interface (TCSI) that interfaces to the TPM's TCS commands (not shown); and 3) TCG service provider interface (TSPI) that interfaces with the TCG's TSP commands (not shown) and sits just below the application. On the TPM side, the TDDL sits on top of the vendor specific TPM device driver, which is in communication with the TPM.
The TDDLI ensures that different implementations of the TSS will properly communicate with any TPM, will provide an OS-independent interface for TPM applications, and will allow the TPM vendor to provide a software TPM simulator as a user mode component. The TDDL provides a transition between user mode and kernel mode on the platform. The TCG core services (TCS) provides an interface to a common set of platform services. The TCS provides the following four core services: 1) context management, which implements threaded access to the TPM; 2) credential and key management, which stores credentials and keys associated with the platform; 3) measurement event management, which manages event log entries and access to associated PCRs; and 4) parameter block generation for serializing, synchronizing, and processing TPM commands.
The TCG service provider (TSP) is a C interface to the TPM, based on an object-oriented architecture. The TSP resides within the same process address location as the application. Authorization takes place in this layer, either though using a user interface coded to this layer or via a callback mechanism at the TCS layer. In order to provide a standardized authorization interface to end users, authentication services are not provided by local application, but rather, by the platform.
The TSP provides two services: 1) context management; and 2) cryptography. The context manager provides dynamic handles that allow efficient usage of application and TSP resources. Each handle provides a context for a set of interrelated TCG operations. Different threads within the application may share the same context or may acquire separate contexts.
To make full use of the TPM protected functions, supporting cryptographic functions must be provided. The TSP does not provide this support except that which is necessary to perform operations required by the TPM specification. In particular, bulk data encryption is not exposed by the interface. Examples of TPM-specified cryptographic functions include message digesting and encryption of a small amount (less than 1024 bytes) of data.